Before two interconnected electronic devices can pass data between one another it is typical for them to communicate with one another to notify each other of their presence and their readiness to communicate. This preparatory process is known as handshaking and involves an exchange of preparatory messages between the two devices. If this exchange is successfully performed, a communications session between the two devices can be initiated and data can be passed between the two devices. Motivation for establishing such communications are numerous including the streaming of video data from a Server to Client, the exchange of voice data for Internet telephony purposes or remote file transfer.
Numerous different protocols for different applications utilise handshaking. One such protocol is SIP (Session Initiation Protocol) (see IETF RFC 3261). This protocol involves the use of a three-way handshake in order the initiate a session or call. A diagrammatic representation of an example of the handshake used to set up a call can be seen in FIG. 1. In this example, the handshake involves the Client transmitting an “INVITE” request message to the Server A, inviting the Server to initiate a session. Server A responds by sending a “200 OK” response to the Client. The Client therefore knows that Server A is online and ready to initiate a session. The Client responds to the “200 OK” message by sending an “ACK” message to Server A. The Client then considers the communication session to be active and readies itself to transmit and receive streams of data to and from Server A.
A weakness with this method is that no response or acknowledgement of the “ACK” message is sent by Server A and so the Client must assume that the ACK message is received. Server A may go into a state where it cannot receive data, for example due to a network failure or due to Server A crashing, after Server A has transmitted the “200 OK” response, see FIG. 2. In this case the Client will consider the three-way handshake to be complete, since Server A is not expected to send a response to the “ACK” message and the Client has no way of knowing of the failure of the delivery of the “ACK” message. The Client therefore assumes the call is active and proceeds to send data. However, as the Server is not available, any data will not be received.
It is common practice for electronic devices to refer to each other using domain names or hostnames. Domain names are resolved into IP addresses using DNS lookup tables, usually stored on DNS Servers which are updated as an IP address changes. However, to avoid frequent and repeated references to the same data, devices can keep logs of domain name lookup results in a local DNS cache. In the future, when trying to resolve a previously encountered domain name, the Client will first consult the locally stored DNS cache thus negating the need to consult the DNS Server. If no entry for a given domain name exists in the DNS cache, the DNS server will be consulted. This method can greatly accelerate the domain name resolution process. However, in this scenario, the use of a DNS cache introduces further problems.
In the scenario depicted in FIG. 3 the Client attempts to handshake with a Server corresponding to the domain name “sip.example.com”. The Client performs a DNS lookup (since initially there is no entry in the DNS code for this domain) which returns two IP addresses, “1.2.3.4” and also “5.6.7.8”. IP address 1.2.3.4 is selected and a record of “sip.example.com” resolving to “1.2.3.4” is added to the DNS cache. The Client transmits (S1) an “INVITE” message to the IP address “1.2.3.4”, where it is received by Server A. Server A responds (S2) by sending a “200 OK” message to the Client. The “200 OK” message includes a contact address (in this case sip.other.com) for the Client to use for further communication. After sending the “200 OK” message, Server A goes offline (S3) such that it cannot receive data from the Client.
The Client has no entries in the DNS cache for “sip.other.com” and so performs a DNS lookup resolving it to “1.2.3.4” and “5.6.7.8”. The resolution of “sip.other.com” resolving to “1.2.3.4” is added to the DNS cache. The Client sends the “ACK” message to “1.2.3.4” but it is never received. The Client believes that the session is active but the Server is either unavailable or does not receive the “ACK” message and so does not consider the handshake complete.
The Client then sends (S5) a new “INVITE” message to “sip.example.com” at “1.2.3.4” as stored in the DNS cache. With Server A unable to receive data, no “200 OK” message is sent back to the Client. After a period of time, the Client concludes that there is a problem at “1.2.3.4” and that the Server at this address is unavailable. The Client deletes this entry from the DNS cache.
The Client then performs a new DNS lookup for “sip.example.com”. Based on the lookup, the Client obtains the alternative IP address, “5.6.7.8” as the resolution for “sip.example.com” and adds this result to the DNS cache. The Client then transmits (S6) the “INVITE” message to “5.6.7.8” where it is received by Server B.
Server B responds (S7) to the Client with an “200 OK” message containing the contact header specifying the contact domain name “sip.other.com”. The Client receives this message and looks up the address for sip.other.com in its DNS cache which returns address 1.2.3.4. The Client then sends (S8) an “ACK” message to “sip.other.com” at “1.2.3.4”. This message does not reach its destination as this IP address corresponds to the unreachable Server A.
Under these circumstances the “ACK” will never be delivered as Server A is unavailable and the DNS cache entry for “sip.other.com” will never be renewed since the Client does not receive any information regarding the failure of the delivery of the “ACK” message to “1.2.3.4”. Steps S6 to S8 can repeat numerous times with the handshake failing each time because the cache entry for “sip.other.com” is never freed. This will prevent a successful call being set up between the Client and Server B.
An alternative protocol, SCTP (Streaming Control Transport Protocol), exists which uses the concept of counting the number of transmissions to detect failure of a path or association. This protocol acts as a faster way to detect transport failures for SCTP as the timeout periods for connected transports are often quite large. It is only used by the transport layer of a device however and does not provide enough information to trigger failure of a specific message/signal that is sent by a device. One solution is to avoid the use of DNS hostnames and simply sent the IP address in the “200 OK” message but this is problematic because it is not always possible to control the Server operation which may not be in the user's own network and also there are advantages to using hostnames rather than IP addresses.
Another option is to disable DNS cache lookups for ACK requests but this results in a significant performance degradation for the SIP Client.
The present invention aims to ameliorate some of the problems with the above-referenced system.